Secure authentication using digital certificates

ABSTRACT

The present invention provides in a method for providing secure authentication using digital certificates, an improvement to enable the selective transfer of authentication data. The said method comprises presentation of basic authentication data certified by an accepted certifying authority, at the commencement of a secure transaction and transfer of additional individual authentication data units against specific requests, as and when required, thereby eliminating the risks associated with providing any authentication data that is not required for a particular transaction.  
     The instant invention also provides a system and configured computer program product for carrying out the above method.

FIELD OF THE INVENTION

[0001] The present invention relates to an improved method, system andcomputer program product for providing a secure authentication usingdigital certificates.

BACKGROUND OF THE INVENTION

[0002] Security is one of the prime concerns in internet applicationsthese days. SSL is the most common means of securing communication. ForAuthentication, SSL and almost all other protocols use DigitalCertificates or UserId/Passwords. Other Authentication means includeBiometrics etc. Normally, in e-business related applications, the serveris authenticated using a Certificate signed by a Certifying Authority.The authentication of the client is mostly dependent on the application.Sometimes it is done via UserId Password, sometimes via DigitalCertificates or maybe not done at all.

[0003] The authentication, however, is singular and static. There is nomeans to dynamically authenticate the user. The problem is described inmore detail below.

[0004] In SSL (Secure Socket Layer), the client needs to have acertificate signed by a Certificate Authority which is listed as trustedin the Servers Trusted Database. This enables it to access theapplication depending upon the access allowed to the user identifiedfrom the certificate. Now often, it is desirable that a user acts as tworoles. A typical example would be a manager acting on behalf of hisemployee who may be on leave etc. In such cases, the server will notaccept another certificate unless the session is broken and a new oneestablished. Practically, speaking this means closing the browser or theapplication or wait for sometime for the timeout.

[0005] In SET (Secure Electronic Transaction), the client needs aDigital Credit Card i.e. special Digital Certificate with users' CreditCard information to buy things online. Now, he might wish to use onecard for some items while use another card for the other items.

[0006] In SET, from the Merchant point of view also, he might wish tooffer some certificate to a group of clients and some to other. That isto say, if the client wishes to buy high valued items, the server wishesto present Certificate-A and if the client is buying low priced items,he wishes to present Certificate-B. A typical example would be amerchant who wishes to place his money from Diamond items in one bankand the rest in another. Another example would be a number of merchantsselling stuff from a single mall/store. They would like to present theirown certificates during payment on the SET protocol.

[0007] In Secure Email applications, the client authenticateshimself/herself using the Email Certificate i.e. a special DigitalCertificate with users' email information. With internet users havingmore than one email IDs, the requirement to change their Emailpreferences is all the more relevant even in case of personal desktop.Users may wish to send some mails using their official ID and othersusing their personal ones (hotmail etc).

[0008] In Secure Email applications, if the desktop is shared betweenusers, the next user will have to close and open the application to viewhis mail i.e. to change the certificate. The equivalent of ‘Switch ID’in Notes is not available.

[0009] Another major problem comes in applications that are providingall the above. They have some applications that require normalauthentication using Digital Certificates. Simultaneously, they mightalso have a store where users can buy using SET certificates. He mightalso provide his users with the Secure Mail option. Now each of thesewould require a different type of X509 Certificate or a combinedCertificate with all the 3 extensions.

[0010] The problem with 3 different certificates has been discussedabove, i.e the user needs to timeout or restart the session to use adifferent service.

[0011] The combined Certificate solves the problem to some extent.However, there are some disadvantages.

[0012] 1. If a new application is to be added, the certificates need tobe reissued and retyped. Example would be: A site implements a SET basedstore and the client get SET Certificates from CAs, however after sometime the site also provides a Secure Email facility. in that case, theusers need to have a combined certificate. SO they have to get a newcertificate. The certificates being issued by the CA also need to bereformatted to have an additional field related to E-mails. This wouldlead to authentication data and present new authentication data andpresent new authentication data as and when required, thereby enablingestablishment of new transactions without the need for closing anexisting session.

[0013] The present invention further provides in a system for providingsecure authentication using digital certificates, an improvement toenable the selective transfer of authentication data comprising:

[0014] means for presenting basic authentication data certified by anaccepted certifying authority, at the commencement of a securetransaction,

[0015] means for transferring additional individual authentication dataunits against specific requests, as and when required,

[0016] thereby eliminating the risks associated with providing anyauthentication data that is not required for a particular transaction.

[0017] The authenticity of said additional individual authenticationdata is established by using the public key provided in said basicauthentication data.

[0018] The authenticity of said additional individual authenticationdata is established by means of signature of said accepted certifyingauthority.

[0019] The said additional individual authentication data is providedwithout the need for establishing a separate session.

[0020] The above improved system further comprises the means forinvalidating previously presented authentication data and present newauthentication data and present new authentication data as and whenrequired, thereby enabling establishment of new transactions without theneed for closing an existing session.

[0021] The present invention also provides in a computer program productcomprising computer readable program code stored on computer readablestorage medium embodied therein for providing secure authenticationusing digital certificates, an improvement to enable the selectivetransfer of authentication data comprising:

[0022] computer readable program code means configured for presentingbasic authentication data certified by an accepted certifying authority,at the commencement of a secure transaction,

[0023] computer readable program code means configured for transferringadditional individual authentication data units against specificrequests, as and when required,

[0024] thereby eliminating the risks associated with providing anyauthentication data that is not required for a particular transaction.

[0025] The authenticity of said additional individual authenticationdata is established by using the public key provided in said basicauthentication data.

[0026] The authenticity of said additional individual authenticationdata is established by signature of said accepted certifying authority.

[0027] The said additional individual authentication data is providedwithout the need for establishing a separate session.

[0028] The said improved computer program product further comprises thecomputer readable program code means configured for invalidatingpreviously presented authentication data and present new authenticationdata and present new authentication data as and when required, therebyenabling establishment of new transactions without the need for closingan existing session.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The invention will now be described with reference to theaccompanying drawings

[0030]FIG. 1 shows the flow chart of the actions at the client,according to this invention.

[0031]FIG. 2 shows the flow chart of the actions at the server,according to this invention.

DETAILED DESCRIPTION OF THE INVENTION

[0032] In the proposed solution the user presents a General PurposeCertificate called the ‘Identity Certificate’ (IC) (1.1) at the start ofthe secure session. This would essentially be the normal X509certificate with no extensions i.e. it will contain the Public Key ofthe holder alongwith his credentials (Name, Organization Unit,Organization, Address etc) and the Certificate Serial Number andCertificate Authority's Signature.

[0033] Current Certificates look like the image given below. Thiscertificate has been verified i for the following uses: SSL ServerCertificate Email Signer Certificate Email Recipient Certificate StatusResponder Certificate Name: Class 4 Public Primary CertificationAuthority - G2, VeriSign, Inc., US Issued under: Verisign, Inc. Serial:32.88:BE:9A:D2:F5:EB:13:47:FB:7F:C4:20:37:25:F8 Number: Validity: MonMay 18, 1998 to Wed Aug. 02, 2028 Fingerprint:26:6D:2C:19:98:B6:70:68:38:50:54:19:EC:90:34:60

[0034] The identity certificate for the same user could be: Thiscertificate has been verified i: Name: Class 4 Public PrimaryCertification Authority - G2, VeriSign, Inc., US Issued under: VeriSign,Inc. Serial: 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8 NumberValidity: Mon May 18, 1998 to Wed 02, 2028 Fingerprint:26:6D:2C:19:98:B6:70:68:38:50:54:19:EC:90:34:60

[0035] Alongwith the IC, the entities would hold individual bits ofinformation signed by their own private key (which may be signed by theCA or not). These would be called the ‘Application Unit SelfCertificate’ (AUSC) where the AUSC would be different for different bitsof information. Depending upon the transaction the user or the serverwould determine if additional authentication is required (1.2). If suchauthentication is necessary the holder would present the required AUSC(1.3) or continue session (1.4). The AUSCs can be signed by theCertification Authority or may not be signed by the CA. This is optionaland the server has a choice to demand what it requires. This will be aconfigurable option in the web servers configuration file. ClientApplications (including browsers) can also generate these Certificateson the fly in case the CA signature is not required. Clients will alsohave an option to initiate a handshake with the Server in which theywill provide the AUSC to the server.

[0036] At the server end, the server will verify and accept the ICpresented by the client (2.1). It would then determine whether or notany additional authentication was required (2.2) depending on the natureof the transaction as well as configured options. If additionalauthentication is necessary, the server would request such additionaldata (2.3) from the clients. Finally, the server would validate theAUSCs presented by the clients (2.4) by verifying the certification ofthe AUSCs presented by the client by the certification authority andother requirements specified on the configuration data. AUSCs wouldprovide the extra bits of information required to access variousservices on the web site and only relevant AUSCs will be sent by theclient to the server. In case, a similar AUSC has been already provided,it will be overwritten by the new AUSC. The server will have an accesscontrol mechanism (this will be the same as in current applications), inwhich it can administer which Identity Certificates can provide whattypes of AUSCs.

[0037] For example each user can have all the extensions fieldscurrently in a SET certificate in a SET USC. He/She can have his emailinformation in a Email USC. This would enable him to present theinformation selectively as and when required. In other words, the usercan log on to the application with his IC and present his AUSCs as andwhen required.

[0038] An Email USC might look like: This certificate has been verifiedi: Name: Email unit Self Certificate Value: deepakgupta@in.ibm.comIssued under: VeriSign, Inc./Self Serial:32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8 Number. Validity: MonMay 18, 1998 to Wed 02, 2028 Fingerprint:26:6D:2C:19:98:B6:70:68:38:50:54:19:EC:90:34:60

[0039] In the above, after presenting the Identity Certificate, if theuser wishes to use Secure Email, the user may present his/her Email USCto the server and the server will be able to extract the publicinformation, the email Id and other relevant information from the EmailUSC.

[0040] So if a website offers only general secured surfing on its site,the user can only present his IC to the server. This would authenticatethe client to the server. The process of verifying would be the same asis being done for normal X509 Digital Certificates these days. Thiswould include verifying the CA's signature on the Certificate and thenidentifying the user from the name on the Certificate. The point to notehere is that after verification process, the users public key is alsowith the server. The only deviation in the present invention from normalSSL handshake would be that the server would store the clients publickey in the session. This can be persisted in a database or stored in thememory depending upon the type of server/application used.

[0041] Subsequently, the site adds the secure email facility to its website, the user can then also present his/her Email USC to the server.The process of authenticating remains the same as before. However, whenthe client wishes to use the secure email facility, the server asks forthe Email USC from the client which can then be presented. Since theuser is already authenticated, the server holds the public key of theclient. So the signature on the USC (which is of the client) can beverified by the server. Hence the email information of the client ispassed on to the server securely without the CA having to issue anothercertificate. Same holds true for SET based applications and otherapplications.

[0042] Another advantage of the same is that the client can only exposethe required fields to the server and hide the fields it does not wantto show. For example if the client wishes to only surf a secured site,the client would not like to reveal any SET credentials and emailaddress to the server on which the client is surfing. Having a commoncertificate would not help. Having USCs would solve the problemautomatically.

[0043] The client would also have an option in the client software(including browsers) to invalidate a previously presented Certificateand present a new one. This would be similar to implementing the LogOutOption by the websites i.e. a request to break the session and start anew one. Nothing special is being claimed or proposed here except fromthe fact that the option of providing the LogOut option is built in withthe client applications. Currently the web sites provide a link orbutton to do so. Building it in the client applications would allow theusers to change their Identity Certificates also in between withoutclosing their browsers (or other client applications) and restartingthem.

[0044] Working:

[0045] The flow of activities between the Server and the Client, asshown in FIGS. 1 & 2 would be:

[0046] 1. Normal Handshake as in the current protocols with the Clientpresenting the Identity Certificate only. (1.1)

[0047] 2. The server verifies the IC (2.1) and determines whether or notadditional authentication is required (2.2). If additionalauthentication is necessary the server generates a request on the client(2.3)

[0048] 3. The client received the request from the server and determinesthe nature of the additional requirements (1.2). Optionally, the clientmay also itself determine what additional authentication data it needsto send (1.2). The client accordingly presents the required AUSC to theserver (1.3)

[0049] 4. The server verifies the AUSC using clients' public key or byverifying certification by certifying authority, based on requirementsspecified in configuration data (2.4) The Server can specify in theServer configuration, if it will accept AUSCs signed only by the user ofthe signature of the CA is mandatory on the AUSCs also. This would be asper the security requirements of the web site.

[0050] 5. The session continues (1.4) and (2.5). At any point of time,the server can request the client for a particular AUSC. Also, at anypoint of time, the client can initiate and present another AUSC. If asimilar AUSC has been presented before, the previous one will beoverwritten by the new one.

[0051] At the server, each Identity Certificate/User can be given finegrained access. Which user can present which types of AUSC and therights associated with all ICs and AUSCs can be defined. (The mechanismfor the same would be similar to the one used currently for normalDigital Certificates).

[0052] In the above discussion, the examples have been explainedassuming the client having the IC and the ASUCs, however the same can beimplemented at the server side also. This would allow the websites toswitch their certificates depending upon the activities of the client.The reasons for having multiple certificates at server can be many. Arelevant situation would be a merchant in SET who wished to switch hisBank if the client is buying high valued items OR he may wish to put hismoney from some special items in a separate acquirer Bank OR he may wishto have higher bit encryption for high valued items and so on.

[0053] The examples have mentioned SET and Secure Email, however theyare only examples, the solution is towards all applications that requireDigital Certificates and special extensions to the same.

[0054] The proposed solution is also scalable and any new applicationthat comes in future can be simply added in the framework by means of asimple new Application USC.

1. In a method for providing secure authentication using digitalcertificates, an improvement to enable the selective transfer ofauthentication data comprising: presentation of basic authenticationdata certified by an accepted certifying authority, at the commencementof a secure transaction, transfer of additional individualauthentication data units against specific requests, as and whenrequired, thereby eliminating the risks associated with providing anyauthentication data that is not required for a particular transaction.2. The improved method as claimed in claim 1 wherein the authenticity ofsaid additional individual authentication data is established by usingthe public key provided in said basic authentication data.
 3. Theimproved method as claimed in claim 1 wherein the authenticity of saidadditional individual authentication data is established by signature ofsaid accepted certifying authority.
 4. The improved method as claimed inclaim 1 wherein said additional individual authentication data isprovided without the need for establishing a separate session.
 5. Theimproved method as claimed in claim 1 further comprising the facility toinvalidate previously presented authentication data and present newauthentication data and present new authentication data as and whenrequired, thereby enabling establishment of new transactions without theneed for closing an existing session.
 6. In a system for providingsecure authentication using digital certificates, an improvement toenable the selective transfer of authentication data comprising: meansfor presenting basic authentication data certified by an acceptedcertifying authority, at the commencement of a secure transaction, meansfor transferring additional individual authentication data units againstspecific requests, as and when required, thereby eliminating the risksassociated with providing any authentication data that is not requiredfor a particular transaction.
 7. The improved system as claimed in claim6 wherein the authenticity of said additional individual authenticationdata is established by using the public key provided in said basicauthentication data.
 8. The improved system as claimed in claim 6wherein the authenticity of said additional individual authenticationdata is established by means of signature of said accepted certifyingauthority.
 9. The improved system as claimed in claim 6 wherein saidadditional individual authentication data is provided without the needfor establishing a separate session.
 10. The improved system as claimedin claim 6 further comprising the means for invalidating previouslypresented authentication data and present new authentication data andpresent new authentication data as and when required, thereby enablingestablishment of new transactions without the need for closing anexisting session.
 11. In a computer program product comprising computerreadable program code stored on computer readable storage mediumembodied therein for providing secure authentication using digitalcertificates, an improvement to enable the selective transfer ofauthentication data comprising: computer readable program code meansconfigured for presenting basic authentication data certified by anaccepted certifying authority, at the commencement of a securetransaction, computer readable program code means configured fortransferring additional individual authentication data units againstspecific requests, as and when required, thereby eliminating the risksassociated with providing any authentication data that is not requiredfor a particular transaction.
 12. The improved computer program productas claimed in claim 11 wherein the authenticity of said additionalindividual authentication data is established by using the public keyprovided in said basic authentication data.
 13. The improved computerprogram product as claimed in claim 11 wherein the authenticity of saidadditional individual authentication data is established by signature ofsaid accepted certifying authority.
 14. The improved computer programproduct as claimed in claim 11 wherein said additional individualauthentication data is provided without the need for establishing aseparate session.
 15. The improved computer program product as claimedin claim 11 further comprising the computer readable program code meansconfigured for invalidating previously presented authentication data andpresent new authentication data and present new authentication data asand when required, thereby enabling establishment of new transactionswithout the need for closing an existing session.